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made the first day. 
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High Level Design Unit Test Results 
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Results 
Detailed Design Source Code 
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Architecture & High Level Design (HLD) _ tiv, 


= Anti-Patterns: Navigator 


e Skipping from requirements to code 


e No picture that shows how all the 
components fit together 


e “Wedding cake” layer diagram that 
omits interface information 





hardware (CPU, MPEG2-decoder, remote control) 


https://goo.gl/J8MAuK 


= Elements of High Level Design 
e Architecture: boxes, arrows, interfaces 
— Arrows/interfaces show communication paths between components 
— Recursive: one designer's system is another designer's component 


e High Level Design (HLD) = architecture (nouns) + requirements (verbs) 


— Sequence Diagrams (SDs) show interactions © 2020 Philip Koopman 3 
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Architecture: Boxes and Arrows ie 


University 
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ee 
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a Softwal re architecture aa cares sean 
shows the big picture 
Boxes: software modules/objects ee 
Arrows: interfaces : <b: 
Box and arrow semantics well-defined aoe 
—- Meaning of box/arrow depends on goal 
Components all on a single page sa Tans SS tacos 
- Nesting of diagrams is OK et ei 


To Higher and Lower Level 
World Modeling 


= Many different architecture diagrams are possible, such as: 

Software architecture (components and data flow types) 

Hardware architecture with software allocation 

Controls architecture showing hierarchical control 

Call graph showing run-time hierarchy © 2020 Philip Koopman 4 
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Sequence Diagram as HLD Notation Es Meter 


= SD construction: 
e Each object has a time ! : , 
column extending downward } 
e Arcs are interactions vent #1. oe 
between objects ! : a . 


Side Effect 


. Event #4 _: 7 
| Postcondition Postcondition 





m Each SD shows a scenario 
e Top ovals are preconditions 
e Middle ovals are side effects 
e Bottom ovals are postconditions 


© ANIL 


= SD is a partial behavioral description for objects 
e Generally, each object participates in mu/tip/e SDs; each SD only has some objects 


e The set of all SDs forms the HLD for all objects in the system © 2020 Philip Koopman 5 
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Example Sequence Diagram hee 


Legend: Blue = physical objects / Black = microcontrollers with software 
PRE = precondition / POST = postcondition / other ovals are side effects 


Sequence Diagram 3A: 


: la. Press Coin Return : : I 
ib. mCoihRetum(true) I 





ic. mCoinReturn(false) I 
I 2a. CoinOut(true) ! 


I 2b. CoinOut{false) I 
=——j 


I 
) 
I 
I 


2c. mCoinCount({1) 
2d. CoinOut{(true) 


I 2e. CoinOut(febe) 1 
<<. 


2f. mCoinCount(0) 


POST: CoinCount==0 | 
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Use Cases to Sequence Diagrams 


Mellon 











University 
m Use Case diagram — types of interactions sail Use Cases 
e System has multiple use cases 
e Example: Use Case #1: Insert a coin 
m Scenario — a specific variant of a use case 
e Each use case has one or more scenarios 
— Scenario 1.1: insert coin to add money The sd mache inten Scenario 
- Scenario 1.2: insert excess coin (too many inserted) settee 
— Scenario 1.3: ... some other situation... "These ine sone aon nr vend 
e Interactions between objects are different for each scenario 
_equence Diagram 
m Sequence Diagram — a specific scenario design = = = aa 
e For our purposes each scenario has one sequence diagram 


— Sequence diagrams 1.1, 1.2, 1.3 show specific interactions 
= Statechart — design that incorporates all scenarios 
e One StateChart per object, addressing all scenarios 
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Combining SDs To Make Statecharts Mellon 


_ University 





= For each object in each SD: identify input & output arcs 
e Detailed Design: design statechart that accounts for all SD behaviors 
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SD set specifies behaviors 
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Soda ended 





: 4d, Vend(false) 
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4f. mCo nCount(0) 












Me. mVend(false) 














Sequence Diagram 1A: 
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eee Te 


1a. Coin Inserted 








CoinControl 


1b. Coinin(true) 


q 1c. CoinIn(false) 


1d. mCoinCount(CoinCount) 








VendControl 





2b. CoinOut(false) 


Statechart Must Exhibit All Those Behaviors 


CoinControl Statechart: State S3.7 VEND 


Do: 


18648 Spring 2010 


CoinCount=0 


istinr2 2f. mCoinCount(0) 


Group 7 
Justin Ray/justinr2 


Set CoinOut to False. 
Set CoinCount to 0. 
Set mCoinCount to CoinCount. 





[T3.11] [13.10] 


State S3.4 OVERPAY State S3.2 COIN_IN_1 


State S3.8 OVERPAY_STRETCH State $3.1 IDLE 


State S3.3 COIN_IN_2 
73.12 . 
U ] Do: Do: 


Set CoinOut to True. _ Do: Set CoinOut to False. 
Decrement CoinCount. Set CoinOut to False. Increment CoinCount. 
Set mCoinCount to CoinCount. Set mCoinCount to CoinCount. Set mCoinCount to CoinCount. 


eee [T3.2] 


Do: 
Set CoinOut to True. 
Set mCoinCount to CoinCount. 


Do: 
Set CoinOut to False. 
Set mCoinCount to CoinCount. 





State S3.5 RETURN_1 State S3.6 RETURN_2 






Do: Do: 


Set CoinOut to True. ' 
Set CoinOut to False. 
——e Decrement CoinCount. Set mCoinCount to CoinCount 


Set mCoinCount to CoinCount. 


State S3.9 RETURN_STRETCH 


Do: 
Set CoinOut to False. 
Set mCoinCount to CoinCount. 
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m= HLD should include: 
e One or more architecture diagrams 


— Defines all components & interfaces 
— HW arch., SW arch., Network arch.., ... 


e Sequence Diagrams 


— Both nominal and off-nominal interactions 
— See 18-649 soda machine for a fully worked example 


e HLD must co-evolve with requirements 


— Need both nouns + verbs to define a system! 


= High Level Design pitfalls: 


Diagrams that leave out interactions 

Boxes and arrows dont have well defined meanings 
HLD that bleeds into detailed design information 

— Should have separate Detailed Design per component 


High Level Design Best Practices —__ititw 
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Vending Machine Architecture Diagram 
(revised 2010-01-17) 
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https://users.ece.cmu.edu/ 
~koopman/ece649/project/ 
sodamachine/index.html 
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I SAD— 
TI KNOW! IM DEVELOPING 
A SYSTEM PASS YOU 
\. ARBITRARY CONDIMENTS. 


‘ITS BEEN 20 
| MINUTES! 


ITLL SAVE TIME 
IN THE LONG RUN! 























https://xked.com/974/ 


